Terminal applications are widely used on self-service terminals (SSTs) to enable the SST to operate and to provide services to users of the SST. SSTs are public-access terminals that are used by members of the public to conduct transactions and/or to receive information in an unattended/unsupervised environment. SSTs are typically ruggedized, tamper resistant, and include software with advanced error handling capabilities to ensure that the SST is inherently resilient to internal failure or external attack. One common type of SST is an automated teller machine (ATM).
An ATM allows a user to conduct a financial transaction or to view financial information by providing a terminal application that controls the ATM. Like many complex software applications, ATM terminal applications are constructed from software components that are linked to form an operational application.
Terminal applications typically have four main types of components, namely: channel services, business services, channel application, and management services. Each of these four types contains multiple components.
The channel services components provide the ATM-specific software needed to operate devices (keypad, cash dispenser, and such like) within the ATM. The business services are components that provide a business function (such as a transaction authorization, a targeted advertisement, a balance enquiry, and such like). Business services and channel application components typically interact with channel services components through an industry standard interface (such as the CEN XFS interface), which enables them to issue industry-standard commands to any ATM, or other SST that is compliant with this industry-standard. This standard interface ensures that the business services components (that perform business functions) are independent of any specific model of ATM (or other SST). The channel application is the application layer that controls the services offered by the ATM. The channel application determines what business services will be offered to which user, and includes application flow logic and screens, as will be described in more detail below.
The application flow (sometimes referred to as the transaction flow) comprises: (i) the sequence of screens that are (or may be) presented to a user to gather information from the user to fulfil the user's request, and (ii) the logic that controls which screen is displayed, that branches to the next screen to be displayed in response to a user input or activity, that collates inputs received from the user, and that requests a business service to fulfil a selected transaction. The term application flow can refer to the actual sequence of screens seen by the user, or to a combination of the sequence of screens and the logic (software) that controls the screens and collates the user inputs.
The term “screen” is used herein to denote the graphics, text, controls (such as menu options), and such like, that are presented on an ATM display; the term “screen” as used herein does not refer to the hardware (that is, the display) that presents the graphics, text, controls, and such like. Thus, as used herein, “screen” refers to content, and “display” refers to hardware that presents the content.
When a transaction is being entered at an ATM, a series of screens is presented on the ATM display to lead a user through a transaction, the next screen displayed being dependent on a user entry or activity relating to the current screen. Each screen in the sequence represents a state within a given application flow. For example, a first screen may request a user to insert a card; once a card has been inserted the application flow logic advances to a second screen that may invite the user to enter his/her PIN; once the final digit of the PIN has been entered, the application flow logic advances to a third screen that may invite the user to select a transaction from a list of transactions (cash withdrawal, printed statement, balance enquiry, deposit, and such like); and so on until the transaction is fulfilled.
The fourth type of component (the management services components) handle management of the devices within the ATM (for example, a cash dispenser, receipt printer, journal printer, serial bus, and such like), consumables used by the ATM (for example, paper for a receipt printer, paper for a journal printer), and software executing on the ATM (channel services, channel application, and business services).
Depending on the business services to be provided to ATM users, and the physical configuration of an ATM (for example, the devices installed), different software components from the four main types of components will be required. To state this another way, the software components required will typically be a subset of components from each of the four main types of components. This means that there must be a customized software build for each ATM configuration. To enable the selected types of software components to operate together, these software components must be configured and related together as part of a custom ATM application for the particular business services offered and ATM devices installed.
In prior art applications, the relationships between these software components were typically created using one of two methods.
The first method is to program the software components together using source code (for example, C++) and compile them into an application. This process of combining the software components is a programming task that requires skill and a process (compilation and deployment) that inhibits rapid change of the application. However, this process is “type-safe”, which means that the validity of the application (validating the software components will work together) is checked. Type-safe code cannot perform an operation on an object that is invalid for that object.
The second method is to script the software components together using a scripting language (for example, Javascript), which is interpreted by the ATM at runtime. This process of combining the software parts is a faster programming task and does not involve compilation, but it is not “type-safe”, so the validity of the application is not checked.
It is among the objects of an embodiment of the present invention to provide a terminal application that obviates or reduces the problems associated with prior art methods of creating relationships between software components.